Diagnostic system in an engine management system

ABSTRACT

A diagnostic system in an engine management system is provided for generating a diagnostic trouble code (DTC) to indicate the operational status of a component or a sub-system. The diagnostic system includes a diagnostic function module (DF module) for each DTC or a group of related DTCs associated with a component or sub-system. The DF module includes means for executing an evaluation routine to evaluate a component/sub-system to which the DTC of the specific DF module relates, and a dynamic scheduler for determining which DF module may be allowed to execute an evaluation routine at a particular time. Each DF module includes means for producing a ranking value dependent on the operating status of the component or sub-system being evaluated, a ranking value being generated each time an evaluation routine is performed; means for processing and storing statistical results of the ranking values obtained over a number of evaluation routines; means for evaluating the statistical results to produce evaluated data in the form of either an evaluated no-fault signal or an evaluated fault signal, and means for establishing the priority of the associated evaluation routine, and means for transmitting the evaluated signals to the dynamic scheduler.

TECHNICAL FIELD

The present invention relates to a diagnostic system in an enginemanagement system for generating a diagnostic trouble code (DTC) toindicate the operational status of a component or sub-system which isbeing evaluated by the diagnostic system.

The invention also relates to a dynamic scheduler for determining theorder of execution of a plurality of engine control functions and aplurality of evaluation routines in a diagnostic system.

The invention further relates to a DF (diagnostic function) module forexecuting an evaluation routine during a driving cycle to detect a faultin a component or sub-system in an engine management system, forgenerating a diagnostic trouble code (DTC) to indicate the operationalstatus of the component or sub-system, and for determining the prioritywith which the evaluation routine should be executed.

BACKGROUND OF THE INVENTION

In order to ensure that drivers of vehicles are made aware of any faultswhich may arise in an engine management system, self-diagnostic systemsare employed to monitor the components or sub-systems in the enginemanagement system and to communicate a warning to the driver should afault be detected. Such a warning may be in the form of a malfunctionindication lamp (MIL) which is illuminated on the vehicle dashboard.Depending on the severity of the fault, the driver may be instructed tovisit a workshop immediately to have the fault rectified or, in the caseof a minor fault, he may wait until the next scheduled visit to theworkshop.

For certain engine management systems, primarily those which affectexhaust emissions, legislation dictates how frequently and under whatcircumstances diagnostic checks are to be performed. Accordingly,standard driving cycles exist during which all diagnostic checks must becompleted. Legislation also requires that, should certain faults bedetected during two consecutive driving cycles, these faults bepermanently recorded in a memory so that they may be later accessed inthe workshop.

Examples of engine management systems include an engine control module,an exhaust gas recirculation system, an evaporated fuel processingsystem, a secondary air system and a catalytic converter monitoringsystem. Further components which require monitoring may include anengine coolant temperature sensor, a mass air flow meter sensor, anengine speed sensor, etc. Whilst the functioning of some components canbe checked virtually independently of the operating conditions of theengine, many components and systems can only be checked when certainoperating parameters prevail, e.g engine load, temperature, enginespeed, etc.

Accordingly, diagnostic systems have been developed which prioritizecertain diagnostic checks over others. For example, a priority system isdescribed in U.S. Pat. No. 5,331,560 in which certain diagnostic checkscan be interrupted if operating conditions dictate that a diagnosticcheck can be performed on an engine management system for which thenecessary operating parameters only rarely occur. Once the existingdiagnostic check has been interrupted, the prioritized check can then beperformed.

Due to the interrelationship between many components and sub-systemsmaking up the engine management system, if operating conditions are suchthat a diagnostic check may be performed on one component or sub-system,it is necessary to inhibit diagnostic checks on other components orsub-systems which may otherwise affect the validity of the result of thediagnostic check. For conventional diagnostic systems, this implies thatif a component or sub-system is added or deleted, the diagnostic systemmust be reprogrammed to ensure that the diagnostic system is aware ofthe effect of the new/deleted component or sub-system on the remainderof the engine management system. Naturally, the same problem arises whenit is desired to implement the same diagnostic system in a differentvehicle model.

The above-mentioned interrelation between various components andsub-systems further implies that should a fault be detected in onecomponent, the effect of the fault may be reflected during diagnosticchecks performed on several components or sub-systems. It is thereforedesirable that means be available to accurately determine where the rootcause of a fault lies and that no false fault signals be recorded.

This interrelationship also means that there may be engine controlfunctions (EC), the execution of which would interfer with the executionof one or several diagnostic functions. For this reason it is desirablethat the diagnostic system can prevent the simultaneous execution ofdiagnostic functions and engine control functions which interfer witheach other.

In order to assist the workshop or manufacturer in determining why acertain fault has arisen, it would be useful to be able to obtaininformation pertaining to the actual operating conditions of the vehiclefrom the time the fault arose up to the point when the fault wasdetected. This possibility has not been available up until now.

SUMMARY OF THE INVENTION:

It is therefore an object of the present invention to provide adiagnostic system which quickly identifies faults, particularly incomponents or sub-systems relating to exhaust emissions, and which caneasily be adapted to different engine and vehicle models.

This object is achieved by a system according to claim 1.

By grouping everything needed for each component or sub-system in aspecific DF module to (i) determine the priority with which theevaluation routine associated with that DF module should be executed,(ii) perform an evaluation routine to detect a fault, (iii) store theevaluated results statistically, (iv) filter the evaluated results todecide when to create DTC-data and, preferably, (v) decide in the casewhen reported valid when to store or erase the DTC-data and when toilluminate or extinguish the MIL, and by controlling the order ofexecuting the evaluation routines of all the DF modules in thediagnostic system from a single dynamic scheduler, the diagnostic systemcan be quickly adapted to changes of components or sub-systems sinceeach DF module will be independent of the others.

A further object of the present invention is to provide a DF modulewhich contains sufficient means to be able to decide independentlywhether certain data is to be stored.

This object is achieved by the DF module according to claim 12.

Preferred embodiments of the present invention are detailed in thedependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS:

The invention will be described in greater detail in the following byway of example only and with reference to the attached drawings, inwhich

FIG. 1 is a block diagram of a diagnostic system according to thepresent invention;

FIG. 2 is a schematic representation of a diagnostic trouble codegenerated within the diagnostic system according to the presentinvention;

FIG. 3 illustrates a possible scheduler table for use within a schedulerlocated in the diagnostic system according to the present invention;

FIG. 4 illustrates a possible scheduler list for use in the diagnosticsystem according to the present invention;

FIG. 5 illustrates a possible freeze frame table and extended freezeframe table for use within a DTC-data area located in the diagnosticsystem according to the present invention;

FIG. 6 illustrates an example of a DTC-block for use in the diagnosticsystem according to the present invention;

FIG. 7 is a schematic representation of a rotating buffer for use withina data collector located in the diagnostic system according to thepresent invention;

FIG. 8 is an example of an extended freeze frame;

FIG. 9 illustrates a validator setup list and corresponding validatorchecklist, and

FIG. 10 illustrates a flowchart for initialization of a validatorchecklist.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In FIG. 1, reference numeral 10 generally denotes a diagnostic systemaccording to the present invention. The system includes a plurality ofdiagnostic function modules (hereinafter referred to as DF modules) 20,20′, 20″, with each DF module serving a component or sub-system, theoperating status of which is to be evaluated. Examples of suchcomponents and sub-systems are an oxygen sensor in the exhaust pipe, anair leakage detection circuit, fuel injectors, an exhaust gasrecirculation system, an engine coolant temperature sensor, a mass airflow sensor, an idle speed control valve, a manifold absolute pressuresensor, an engine speed sensor, a canister close valve, etc. In a mannerwhich will be described later, each DF module 20, 20′, 20″ is arrangedto evaluate its associated component/sub-system and to generate adiagnostic trouble code (hereinafter referred to as DTC) which indicatesthe operational fault status of the component/sub-system. In a mannerwhich will also be described later, each DF module 20, 20′, 20″, isfurther arranged to calculate the priority with which its associatedcomponent/sub-system should be evaluated.

A preferred DTC format, generally denoted by reference numeral 200, isshown in FIG. 2 and consists of a 16 bit code divided into three parts.A first part 201 preferably consists of 8 bits and serves to indicatewithin which engine sub-system, for example the ignition system, fueland air metering system, etc, a fault resides. A second part 202advantageously consists of 4 bits and serves to indicate within whichcomponent of the sub-system a fault resides. Finally, a third part 203,also of 4 bits, is used to indicate the type of fault that has an impacton other components/sub-systems, for example a slow response of an O₂sensor, catalytic converter damage due to misfire, a stuck open valve,etc.

Due to the fact that the engine diagnostic system according to theinvention is arranged to evaluate the operational status of a pluralityof components and sub-systems, and many of these components/sub-systemscan only be evaluated when certain operating conditions are fulfilled,the system 10 further includes a dynamic scheduler 30. The purpose ofthe scheduler is: to coordinate the execution of the differentevaluation routines which are to be run by the respective DF modules,and engine control functions (EC), so that it is ensured that as manyevaluation routines as possible can be completed, dependent on theprevailing operating conditions, within a given time interval, at thesame time that no two evaluation routines are allowed to take placesimultaneously if there is a risk that this may result in an erroneousDTC being generated. An example of two evaluation routines which shouldnot be performed simultaneously is a leakage detection check using acanister purge valve and monitoring of the catalytic conversion ratio.

Since many of the diagnostic functions will cause execution of certainengine functions, the dynamic scheduler is also provided with aninterface towards the control functions of the engine, in order to allowor prevent the execution of engine control (EC) functions which wouldinterfer with an engine control function or an evaluation routine whichis being executed at the time. One example of an evaluation routine andan engine control function which cannot be allowed to run at the sametime is the leakage check test and the canister purge function:

The leakage check test is performed to check whether there are any leaksin the evaporative system of the vehicle. This is done by closing theevaporative system, a procedure which includes shutting all connectionsleading from the canister. Air is then drained from the system, untilthe pressure reaches a certain preset level. The leakage check test thenmonitors the pressure inside the now closed system, to see if thepressure changes, thus indicating the absence or presence of leaks.

The canister purge function is performed in order to rid the canister offuel which cannot be used, and which would thus be released into theatmosphere, causing unwanted emissions. The canister is purged byintroducing ambient air into the engine, through the canister. Thus, anyfuel remaining in the canister will be used in the engine, together withthe ambient air which was used to “cleanse” the canister. Obviously,this engine control function cannot be performed at the same time as theabove described leakage test function.

Naturally, there are many other such combinations of evaluations andengine control (EC) functions which would “collide” with each other.

Thus, the dynamic scheduler 30 can be said to have both an “inhibitiondue to fault” function, and a “collision controller” part.

Furthermore, if a fault is detected by one DF module, the dynamicscheduler serves to stop evaluation routines that would otherwise beaffected by the fault, i.e these stopped evaluation routines wouldotherwise be “deceived” into believing that a fault exists in theirsystems as well, even though there are no actual faults in thesesystems.

In the event that such an affected DF module performs its evaluationroutine before the evaluation routine on the component/sub-system whichpossesses the actual fault is performed, then the affected DF modulegenerates a DTC indicating a fault in the component/sub-systemassociated with that DF module. Accordingly, it is necessary that thediagnostic system 10 has access to sufficient information to beable-to-verify whether the DTC is valid or not. In other words, thesystem 10 must be able to determine whether the actual fault lies in thecomponent/sub-system evaluated by the DF module which has provided theinitial DTC, or whether the DF module has been “deceived” due to apresent but not yet detected fault in another component/sub-system.

In order to provide the system 10 with information about vehicleoperating conditions prior to the time when the DTC was generated, thesystem further includes a data collector module 40. In a manner whichwill be explained later, the data collector module is arranged to handlethe creation of freeze frames and extended freeze frames. A freeze frameis a sample of a number of parameters which are specific for the actualDTC, such as the actual engine temperature and engine sped at the timethe DTC was generated. An extended freeze frame contains a number ofsamples of a few parameters specific for the actual DTC from the timewhen the DTC was generated and backward in time. On the basis of thisinformation, the data collector module 40 generates a DTC-blockcontaining the DTC and this information.

So that any DTC-blocks generated by the data collector module 40 can bestored, the system 10 is provided with a DTC-data area module 50. In amanner to be described later, when the DTC-data area module 50 receivesa request from the data collector module 40 to save a DTC-block, itsaves the block and sends a DTC-Saved response to the data collectormodule.

To determine whether the saved DTC-block is valid or not, i.e. if afault actually exists or not in the component/sub-system checked by theDF module which generated the DTC, the system 10 is provided with avalidator 60. The validator 60 receives the information that anot-validated DTC-block has been saved from the DTC-data area module 50and, by setting up a validator checklist (to be described), it is ableto decide if the DTC-block is to be considered to be valid or not.

If the validator 60 decides that a DTC-block is valid, then this impliesthat a component or system is malfunctioning. Depending on whichcomponent or system is affected, it may be desirable to inform thedriver of the vehicle of the malfunction. Accordingly, the system 10 isprovided with a malfunction indication lamp (hereinafter referred to asMIL) handler module 70 which can inform the driver of a malfunction bydisplaying an error sign or message on the dashboard of the vehicle.

To permit the engine diagnostic system 10 to be able to communicate withexternal testers used by workshops, the system 10 advantageouslyincludes an external communication handler (hereinafter referred to asECH) module 80.

Finally, the system 10 is provided with a diagnostic system manager(hereinafter referred to as DSM) module 90 which is responsible for thestarting of the diagnostic system once the ignition of the vehicle isturned on and for the stopping of the system when the engine controlsystem has finished all other operations after the ignition has beenturned off. This is accomplished by an interaction with both thediagnostic system and the engine control system, both situated withinthe engine control module of the vehicle.

In order to better understand the functioning of the diagnostic system10 according to the present invention, each module or unit 20, 30, 40,50 and 60 will be described in the following in greater detail.

The DF Module 20

As mentioned previously, each DF module 20, 20′, 20″ serves a componentor sub-system whose operating status is to be evaluated. Accordingly,each DF module 20, 20′, 20″ is arranged to evaluate its associatedcomponent/sub-system and to generate a diagnostic trouble code (DTC)which indicates the operational status of the component/system. Toachieve this, each DF module needs to be able to process all informationneeded for the evaluation of a malfunctioning component or sub-systemsuch as a sensor, emission component, EVAP system, etc. Each DF moduleis also arranged to evaluate the priority with which its associatedcomponent/sub-system should be evaluated.

To this end, and as is apparent from FIG. 1, each DF module 20, 20′ and20″ comprises a plurality of sub-modules including a DF interface 21, aphysical diagnosis (hereinafter referred to as a PD) 22, a DF logger 23,a DF controller 24 and a DTC handler 25.

The DF interface 21 is a DF sub-module which handles transfer ofcommunication from and to DF sub-modules to other modules in thediagnostic system. Since the DTC generated by a particular DF module isunique to that module, the DTC is used as an identifier by other modulesin the system for communicating with that particular DF module.Accordingly, the DF interface 21 is able to recognize all signalsaddressed to a DF module with the identifier that is related to the DFmodule in which the DF interface is located and assigns these signals tothe correct DF sub-module. All signals sent from a DF sub-module to thedynamic scheduler 30, the data collector 40, the DTC-data area 50, thevalidator 60, the MIL handler 70 or the ECH module 80 are transferredvia the DF interface 21.

The PD 22 is a DF sub-module which contains an evaluation routine foreach DTC that is related to the particular DF module. The PD 22 is ableto recognise when the engine operating conditions are fulfilled whichwill allow the DF-module to evaluate its associated sub-system orcomponent. Each time these conditions are met, the PD 22 informs the DFcontroller 24 that it is possible to perform the evaluation routine. ThePD waits for the DF controller to give permission before executing theevaluation routine.

If, during an evaluation routine, the engine operating conditions changesuch that the conditions no longer coincide with those which arenecessary to be able to perform the evaluation routine, the PDinterrupts the routine. Similarly, if the DF controller 24 withdraws thepermission to execute the evaluation routine, the PD interrupts theroutine.

In order to ascertain whether a possible fault is present, every time anevaluation routine is completed, the PD 22 produces a ranking value asan indicator of the status of the checked component/sub-system.Preferably, each ranking value lies in the range from 1 to 255, with thevalue 128 corresponding to a normal component or sub-system, for examplethe idle air adaptation value equal to a calibrated reference. The value255 corresponds to a component or sub-system that is not working at all,for example the idle air adaptation value at maximum. Eachcomponent/sub-system is assigned a high fault limit and providing thatthe ranking value lies below the high limit, no fault will be indicatedand an evaluated “no-fault” data signal is generated. Should the rankingvalue exceed the high limit, an evaluated “fault” data signal isgenerated. Each time the evaluation routine is completed, the evaluateddata signal is sent to the DF controller 24 and the ranking value issent to the DF logger 23.

The DF logger 23 is a DF sub-module that receives the ranking values anduses the highest of a specific number of ranking values to be processedstatistically and the results are stored for use as information for theworkshop.

The DF controller 24 is a DF sub-module that controls the PD 22. Thus,when the PD informs the DF controller that it is possible to run theevaluation routine, a response is sent to the dynamic scheduler that theevaluation routine is inhibited, along with information regarding thepriority of that evaluation routine. When/if the dynamic scheduler 30sends a response that the evaluation routine may be performed, the DFcontroller 24 permits the PD to run the routine. If the dynamicscheduler 30 sends a request to inhibit the evaluation routine, the DFcontroller withdraws the permission to run the evaluation routine andwhen the evaluation routine has stopped, it sends an “inhibited”response to the dynamic scheduler.

The DF controller 24 also receives all evaluated data signals andinforms the dynamic scheduler 30 of any change in status of theevaluated data signals defined as the latest evaluated data signal. TheDF controller demands a consecutive number of evaluated “fault” datasignals to be generated before it produces a controlled “fault” datasignal. The actual number of consecutive signals required to bring aboutthis change in condition is specific for each DTC that is to begenerated. At ignition, the controlled data signal is set to “not-done”and at the first evaluated “no-fault” data signal, the controlled datasignal is set to “no-fault”.

Once the DF controller 24 produces a controlled “fault” data signal, itsends a request to the data collector module 40 to create DTC data. Onceset, it is not possible to change the controlled “fault” data signal forthe remainder of the driving cycle (until ignition off).

As mentioned above, the DF controller 24 also calculates the prioritywith which the evaluation routine associated with that particular DFmodule should be executed. This priority is communicated to the dynamicscheduler 30. In a preferred embodiment, the priority calculation isbased on when the evaluation routine associated with that particular DFmodule was last executed. In a particular embodiment, the evaluationroutines are preferably arranged into four groups, in order of priority:

1) Evaluation functions which have not been executed during the presentor the previous driving cycle.

2) Evaluation functions which have not been executed during the presentdriving cycle, but which were executed during the previous drivingcycle.

3) Evaluation functions which have been executed during the presentdriving cycle, but not during the previous driving cycle.

4) Evaluation functions which have been executed both during the presentdriving cycle and the previous driving cycle.

There are two further levels of priority, both of which are higher thanthe four above-mentioned levels. These two levels are the so called“certification window” level, and the “swift test” level. Of these two,the “swift test” level has the higher priority, i.e. the “swift test”priorirty level is the highest of all the priority levels.

The “certification window” priority level serves to ensure that theevaluation function is performed during a specified “window” in time.This window is usually a period of time, specified e.g. by legislation,during which the function in question must be evaluated.

The swift test level is used e.g. in a workshop, after repairs have beencarried out on the sub-system/component in question, in order to swiftlyascertain whether the repairs have been successful.

The DTC handler 25 is a DF sub-module that is responsible for takingdecisions after the diagnostic system 10 has validated a DTC-block asbeing valid. Its functions include deciding when to store the DTC-blockpermanently, sending a request to illuminate or extinguish themalfunction indication lamp in the MIL handler module 70 and decidingwhen to erase the DTC-block if the fault is no longer detected.

Dynamic Scheduler Module 30

The dynamic scheduler module 30 handles the scheduling of evaluationroutines and engine control (EC) functions. The dynamic scheduler module30 receives requests to run engine control (EC) functions, and alsoreceives requests from the DF modules 20, 20′, 20″ to execute evaluationroutines, and decides which of these engine control (EC) functions andevaluation routines should be performed, and in which order, taking intoaccount:

whether any evaluated “fault” data signals are present,

the priority of the evaluation routines which have been requested,

the priority of the engine control functions which have requested toexecute,

undesired “collisions” between engine control (EC) functions andevaluation routines, and

whether the operating conditions necessary for that particular enginecontrol function or evaluation routine are fulfilled.

The dynamic scheduler module 30 takes into account any latest evaluateddata which it receives from the DF modules and decides whether thisevaluated data implies that certain evaluation routines and/or enginecontrol functions affected by the fault should be inhibited. The dynamicscheduler may also take into account whether a DF module informs thedynamic scheduler module that an evaluation routine has been stoppedbecause the conditions for running the evaluation routine are no longerfulfilled, or inhibited on request from the dynamic scheduler or due todynamic scheduler not yet having sent the run response.

In order to fulfil its requirements, the dynamic scheduler module 30requires access to information relating to what has to be done for eachevaluation routine. This information may be contained in a schedulertable. An example of a possible scheduler table is shown in FIG. 3. Thescheduler table contains all the evaluation routines for the diagnosticsystem and preferably specifies:

the priority level of all evaluation routines dedicated to certainspecified priority groups so that the dynamic scheduler module candetermine which of the requested to run routines has priority withineach priority group, and

which other evaluation routines to inhibit should the latest evaluateddata from a DF module indicate a fault.

In order to function effectively, the dynamic scheduler module alsoneeds information concerning the current status of the evaluationroutines in the diagnostic system. This information is provided by ascheduler list. With reference to FIG. 4, the scheduler list containsfour sub-lists, namely an inhibited list, a running list, a latestevaluated data list and a to-be-handled list.

The inhibited list indicates which evaluation routines have requestedthe opportunity to run but which are not permitted to run. Flags in thislist are set for the evaluation routines that have reported that theyare inhibited and reset for the evaluation routines that have indicatedthat they have ceased due to the physical conditions within the DFmodule or that have been turned off by the dynamic scheduler module.

The running list, as the name implies, indicates which evaluationroutines are presently running. Flags in the running list are set forthose evaluation routines which the dynamic scheduler module has allowedto commence running, and reset for the evaluation routines which arereported to be stopped, inhibited or turned off by the related DFmodules.

The latest-evaluated-data list indicates the current status of theevaluated data for each evaluation. Flags in this list are set for eachevaluation routine that has sent a latest evaluated “fault” data signal,and reset for each evaluation routine that has sent a latest evaluated“no-fault” data signal.

The to-be-handled list is used by the dynamic scheduler module as aworking list to keep track of which evaluation routines remain to behandled because of priority, time and evaluated “fault” data signals.Each time the dynamic scheduler has finished processing the priorityhandler 35, the flags that remain “set” in the to-be-handled list areindications that the associated evaluations should be running, and flagsthat are “reset” are indications that the associated evaluations shouldbe stopped or inhibited.

In the above, and following, descriptions of the tables of FIGS. 3 and4, for reasons of simplicity only evaluation routines have been includedin the tables. The tables may of course, when necessary and desired,include corresponding data regarding engine control (EC) functions.

To execute the required functions, and as is apparent from FIG. 1, thedynamic scheduler consists of a number of sub-modules including a DFSinterface 31, a DFS controller 32, an inhibit handler 33 and a priorityhandler 35.

All signals that are sent from DF modules 20, 20′, 20″ and the ECHmodule 80 to the dynamic scheduler module 30 are identified in the DFSinterface 31 and transferred to the correct dynamic schedulersub-modules. All signals that are sent from the dynamic schedulersub-modules to the DF modules and the ECH module are transferred via theDFS interface 31.

All signals sent to the dynamic scheduler module 30 are checked by theDFS controller 32. The DFS controller updates the inhibited list, therunning list and the latest evaluated data list for signals sent fromthe DF modules 20, 20′, 20″ to the dynamic scheduler module 30. If anyof the three lists has been updated, the DFS controller 32 acts asfollows:

Copy the inhibited list and running list into the to-be-handled list.

Start the inhibit handler 33.

When the inhibit handler 33 is finished, start the priority handler 35.

When the priority handler is finished, perform a “stop routine”, i.e.the DFS controller 32 sends inhibit requests to the evaluation routinesthat are running according to the running list (flags are set) butshould not be running according to the to-be-handled list (flags arereset), and sets the flags in the inhibited list as an indication thatthe dynamic scheduler has requested these evaluations to be inhibited.

When finished with the “stop routine”, a “start routine” is performed,i.e. the DFS controller sends a run response to each of the evaluationsthat should be running according to the to-be-handled list and is eachassociated to a priority group according to the scheduler table in whichno other evaluations are running according to the running list. For eachrun response sent, the DFS controller sets the corresponding flag in therunning list.

When finished, check if there is any signal which has been sent to thedynamic scheduler and if so start to work again.

When a request to stop all evaluation routines is sent from the ECHmodule 80, the DFS controller 32 acts as follows:

Clear the to-be-handled list and start to work (inhibit requests will besent to all evaluation routines that are running).

When finished, update the latest evaluated data list, the running listand the inhibited list according to all signals sent to the dynamicscheduler but do not start to work as in normal operation.

When all flags in the running list are reset, send the response that allevaluation routines have been stopped to the ECH module 80.

Wait only for a request to resume normal operation from the ECH module80.

When the-request to resume normal operation is received, copy theto-be-handled list and start to work as normal.

When a request to turn off all evaluation routines is received from thediagnostic system manager (DSM) module 90, the DFS controller 32 acts asfollows:

Send turn off requests to all evaluation routines.

Update the latest evaluated data list, the running list and therequested-to-run list according to all signals sent to the dynamicscheduler.

When all flags in the running list and inhibited list are reset, send aresponse to the DSM module 90 that all evaluation routines have beenturned off.

Wait only for a general response signal from the DSM module 90 to startthe diagnostic system 10 before starting to work as normal again. Noaction while waiting.

The inhibit handler 33 acts only on a start request received from theDFS controller 32. The inhibit handler 33 first checks the latestevaluated data list to determine which evaluation routines havegenerated latest evaluated “fault ” data signals. For those evaluationroutines which have generated such signals, the inhibit handler 33checks the scheduler table (FIG. 3) to determine which evaluationroutines to inhibit due to reported faults. The inhibit handler 33resets the flags in the to-be-handled list that correspond to theevaluation routines to be inhibited. When finished, the inhibit handlersends a “finished” signal to the DFS controller 32.

The priority handler 35 acts only on a request to start from the DFScontroller 32. The priority handler checks the to-be-handled list toascertain which evaluation routines are to be handled. Using this listand the scheduler table, the priority handler 35 is able to determinewhich of the evaluation routines to be handled are in the same prioritygroup, starting with priority group number 1 in the scheduler table(e.g. X) (FIG. 3). The priority handler resets the corresponding flag inthe to-be-handled list for the evaluation routines that have lowerpriority levels than the evaluation routine that is to be handled andwhich has the highest priority level within the priority group.

When finished with the first priority group, the priority handler 35continues with priority group number 2 (e.g. Y) and so on until allpriority groups have been checked.

If an evaluation routine is assigned more than one priority group, it ishandled as a part of each priority group. The priority level is thenused individually in each priority group.

Since the dynamic scheduler module (30) has an interface towards theengine control (EC) functions of the vehicle, the function of thosecalculation routines in the engine control functions which communicatewith the dynamic scheduler module (30) will be briefly described in thefollowing:

For each of the engine functions concerned, a priority value iscalculated. This calculation takes into account:

the period of time refered to above as “certification window”

whether the conditions necessary for carrying out the engine controlfunction in question are fulfilled

the priority level refered to above as “swift test”

Since the priority levels calculated by two or more engine controlfunctions or evaluation routines may be equal, each caluation routine orengine control function is given a so called “static priority”. If twoor more calculated priorities are equal, a total priority is calculated,the total priority being the sum of the calculated and the staticpriorities.

The Data Collector Module 40

On request from a DF module 20, 20′, 20″ to create DTC-data, the datacollector module 40 is arranged to perform the following functions:

Create a freeze frame (hereinafter referred to as FRZF) with DTCspecific data.

Combine the FRZF with certain information to form a DTC-block.

Create an extended FRZF (measurement over time) with DTC specific data.

Send the DTC-data (DTC-block and extended FRZF) to the DTC data areamodule 50.

Advantageously, the data collector module 40 can also act as an internalflight recorder on request from the ECH module 80.

In order to fulfil these requirements, the data collector module 40requires information concerning the specific parameters for eachevaluation routine which is performed in the DF modules 20, 20′, 20″.This information is provided in a FRZF table and an extended FRZF table.An example of a FRZF table and an extended FRZF table is shown in FIG.5. Each number in the tables denotes a particular parameter.

As mentioned above, the data collector module 40 generates a DTC-block.A DTC-block is a data block that contains information in the form ofparameters pertaining to the operating conditions at the time that theDTC was generated. An example of a possible DTC-block is illustrated inFIG. 6. Thus, the DTC-block consists of certain DTC specific information(DTC, latest and initial DTC-subcode and FRZF delay time) together withthe FRZF and finally a pointer to the extended FRZF.

To be able to create an extended FRZF, which is a measurement over timeof DTC relevant data, the data collector module 40 is provided with acircular memory in the form of a rotating buffer. As shown in FIG. 7,the rotating buffer is generally denoted by reference numeral 110 and isin the form of a drum 111 divided into, in the illustrated example, fourdifferent time bases 112, 113, 114, 115 resp.

An example of an extended freeze frame is shown in FIG. 8.

A global data area, denoted by reference number 120 in FIG. 1, ispositioned externally of the diagnostic system 10 in the engine controlsystem part of the engine control module and contains currentinformation on values for all parameters for all evaluation routines.Each parameter is identifiable by a unique identification number in theglobal data area 120 and is allocated one of the time bases 112, 113,114, 115. The rotating buffer 110 is updated each time any time baseexpires with parameter values associated with the expired time basecopied over from the global data area 120 and these parameters arestored in their respective time base. A pointer 116, 117, 118, 119 toindicate the latest sample to be copied over is placed in front of thelatest sample in each time base. When a time base of the rotating buffer110 is full, the oldest sample is written over in that time base. Inthis manner, the rotating buffer 110 forms a circular memory withseveral time bases, each with equal memory depth but with specific timedepth.

In order to generate DTC-data which will subsequently be forwarded tothe DTC data area module 50 and to handle requests sent from the ECHmodule, the function of the data collector module 40 is divided intosub-modules, i.e a DC interface 41, DC controller 42, FRZF collector 43,extended FRZF collector 44 and a buffer handler 45.

All signals that are sent from the DF modules 20, 20′, 20″ and the ECHmodule 80 to the data collector module 40 are identified by the DCinterface 41 and transferred to the correct data collector sub-modules.All signals sent from the data collector sub-modules to the DTC dataarea module 50 and the ECH module 80 are transferred via the DCinterface 41.

Upon receipt of a request from a DF module 20, 20′, 20″ to createDTC-data, the DC controller 42 requests the FRZF collector 43 to createa FRZF. Upon receipt of this request, the FRZF collector 43 checks theFRZF table (FIG. 5) to determine which parameters specific for this DTCare to be copied over from the global data area 120. The FRZF collectorproceeds to copy the parameters from the global data area and placesthem in the order specified by the FRZF table. When finished, the FRZFcollector informs the DC controller 42 that the FRZF has been created.

When the FRZF collector 43 has informed the DC controller 42 that theFRZF has been created, the DC controller asks the extended FRZFcollector 44 to create an extended FRZF.

Upon receipt of this request, the extended FRZF collector 44 performsthe following acts:

Stop the rotating buffer by sending a stop request to the buffer handler45.

Create an empty extended FRZF of correct size, the empty extended FRZFincluding parameter identification numbers specified by the extendedFRZF table.

Upon receipt of confirmation that the rotating buffer has been stopped,copy over all the parameter values corresponding to the identificationnumbers in the extended FRZF that match the identification numbersspecified in the rotating buffer table from the rotating buffer.

Start the rotating buffer by sending a start request to the bufferhandler 45.

Send a response to the DC controller 42 that the extended FRZF has beencreated.

Using i.a. information provided in the FRZF and the extended FRZF, theDC controller 42 creates DTC-data in the form of a DTC-block (see FIG.6) modified to take account of the extended FRZF.

Once the DTC-data has been created, the DC controller 42 sends a requestto the DTC-data area module 50 to save the DTC data.

After sending the request, the DC controller 42 waits for confirmationfrom the DTC-data area module that the DTCWO data has been saved beforeacting on any new request to create DTC-data.

The DTC-data Area Module 50

The DTC-data area module 50 is divided into four sub-modules, namely aDA interface 51, a DTC-block area 52, an extended FRZF area 53 and a DAcontroller 54.

All signals that are sent to the DTC-data area module 50 from the ECHmodule 80, the data collector module 40, the validator 60 and the DFmodules 20, 20′, 20″ are identified by the DA interface 51 andtransferred to the correct DTC-data area sub-module. All signals sentfrom the DTC-data area sub-modules to the validator 60 and the datacollector module 40 are transferred via the DA interface 51.

The DTC-block area 52 is used for storing the DTC-blocks. The number ofDTC-blocks which can be stored in this area varies from application toapplication, but a typical number is ten. The DTC-block area 52 isalways capable of storing a predetermined maximum number of DTC-blocksplus one. The additional one represents a temporary space which is usedto buffer the incoming data from the data collector module 40. TheDTC-block area 52 uses a free list to keep track of the free DTC-blocks,and a temporary pointer to keep track of the temporary space.

The extended FRZF area 53 is used for the storage of the extended FRZFs.The extended FRZF area 53 is always capable of storing a predeterminedmaximum number of extended FRZFs plus one. The additional one representsa temporary space which is used to buffer the incoming data from thedata collector module 40. The extended FRZF area 53 uses a free list tokeep track of the free extended FRZFS, and a temporary pointer to keeptrack of the temporary space.

The DA controller 54 controls the DTC-block 52 and the extended FRZFarea 53. It receives a DTC-block and an extended FRZF via the DAinterface 51 from the data collector module 40 and the DTC-block andextended FRZF are saved in the applicable data areas.

When the DA controller 54 receives a request from the data collectormodule 40 to save DTC-data, the DA controller saves the DTC-block andassociated extended FRZF and, when this is done, informs the validatormodule 60 that a not-validated DTC-block has been saved and waits for anacknowledge response or any request from the validator. If the validatorsends an acknowledge response, the DA controller informs the datacollector module 40 that the DTC-data has been saved.

If the related DF module sends an acknowledge response, the DAcontroller informs the data collector module 40 that the DTC-data hasbeen saved.

When requested by the validator module 60 to change a DTC-block statusfrom not-validated to valid, or to erase a not-validated or validDTC-block, the DA controller 54 does so and informs the related DFmodule if a valid DTC-block has been erased and waits for an acknowledgeresponse or any request from the related DF module.

When requested by a DF module to change a DTC-block status from valid tostored, or to erase a valid or stored DTC-block, the DA controller doesso and informs the validator module 60 that a valid or stored DTC-blockhas been stored or erased.

If, after sending a response that the DTC-data has been saved, theavailable space is not enough for the next DTC-block, i.e. no temporaryspace is free, the DA controller 54 erases the DTC-block and associatedextended FRZF having lowest priority and informs the validator module 60and related DF module 20, 20′, 20″ that the particular DTC-block hasbeen erased. If there is only not enough space for the next extendedFRZF, the DA controller erases the extended FRZF having lowest priorityand erases the link between the erased extended FRZF and the associatedDTC-block but does not send any information about the event.

At the request to erase all DTCs sent from the ECH module 80, the DAcontroller 54 erases all DTC-blocks and, for each DTC-block erased, itinforms the validator 60 and related DF module.

The Validator Module 60

The purpose of the validator module 60 is to determine the root cause ofa fault. In other words, it is possible that, say, four DTC-blocks withextended FRZFs are generated by the data collector module 40, though infact only one of the DTC-blocks is the true indicator of the fault. Thisis because the fault is deceiving the other affected evaluation routinesso that erroneous controlled “fault” signals are sent from the affectedDF modules to the data collector module 40. The validator thereforeexamines each of the four DTC-blocks (with associated extended FRZFs) todetermine in which component or system the actual fault lies.

Thus, when the validator module 60 is informed by the DTC-data areamodule 50 that a saved DTC-block is present, the validator sets up achecklist that contains all possible root cause evaluation routines thathave to be performed and reported with controlled data as “no fault”before validating the correct DTC, i.e pointing out the DTC-block thatis the root cause of the fault. The content of the validator checklistis stored at ignition of f, i.e. the validation is independent ofignition on/off.

Validator setup-lists are used to set up and initiate checklists. Eachsetup-list contains the DTC-to-validate and a specification of whichevaluations have to be checked before validation of the DTC-to-validate.A validator setup list and corresponding validator checklist isillustrated in FIG. 9.

A checklist is set up according to its set-up list in the followingmanner.

When the validator module 60 is informed by the DTC-data area module 50that a DTC-block has been saved, the validator module searches thesetup-lists for a DTC-to-validate that corresponds to the DTC in theDTC-block. If the DTC is not found in any of the DTC-to-validatepositions in any of the setup-lists, the validator immediately makes theDTC-block valid by requesting the DTC-data area module 50 to changestatus on the DTC-block from not validated to valid.

If the DTC is found, the validator setup-list containing the matchingDTC-to-validate is used to set up a validator checklist specific forthis DTC. The checklist comprises the following items:

A header specifying the DTC being validated (this links the checklist toits setup-list).

A time stamp (elapsed realtime read from the global data area 120).

Flags indicating the status for each evaluation-to-check in thevalidator setup list, a flag being set for controlled no-fault and resetas long as controlled no-fault has not been reported. Theevaluation-to-check linked to each flag is defined in the setup-list.

A validator setup list that has a validator checklist linked to it is,in the following, termed an active validator setup-list.

The validator checklists are updated only on request sent from the DSMmodule 90 at the end of each driving cycle. In the update procedure, thevalidator module requests controlled data from each DF module 20, 20′,20″ defined in the active validator setup-list. Each DF-module respondswith its current controlled data state, i.e. not controlled, controlledfault or controlled no-fault. The response “controlled no-fault” sets acorresponding flag in the validator checklist. The responses “notcontrolled” and “controlled fault” reset the corresponding flag in thechecklist.

When all the flags in the validator checklist are set, the DTC-blockassociated with the DTC-to-validate is decided to be valid and thevalidator module 60 sends a signal to the DTC-data area modulerequesting a change of the DTC-block status from not-validated to valid.The DTC-data area module 50 changes the status and then sends a signalto the applicable DF module that a DTC-block status has changed tovalid.

As illustrated in FIG. 10, when the validator module 60 receives asecond not-validated DTC-block saved signal (Checklist A) from theDTC-data area module that corresponds to an evaluation-to-check in anactive validator setup-list with associated validator checklist(Checklist B), the DTC-block that generated that active validatorchecklist is not considered to be the root cause. Such DTC-block andvalidator checklist (Checklist B) are therefore erased. This is achievedby sending a signal to the DTC-data area module requesting the DTC-blockrelating to the header in the validator checklist to be erased. Upon theresponse that the DTC-block has been erased, the validator erases therelated validator checklist. A new validator checklist is set up for theother DTC-block that caused these events.

When the validator module 60 receives a signal from the DTC-data areamodule 50 that a DTC-block status has been changed from valid to stored,the corresponding validator checklist is erased.

To ensure the relevance of the information in the validator module 60, avalidator checklist reset function is implemented. The reset functionresets all the flags when the validator checklist is older than apredetermined period of time, for example at least 168 hours.

Overall Normal Operation of the Diagnostic System 10 When No Fault isPresent

The overall normal operation to run the different evaluations withcorrect system (i.e. no fault) is described below:

At the signal to start the diagnostic system sent from the DSM module90, each DF module will, as soon as the physical conditions arefulfilled for running its evaluation, send the priority of itsassociated evaluation to the dynamic scheduler module 30. The dynamicscheduler 30 will also receive requests to run from a plurality ofengine functions.

When the dynamic scheduler module receives this information, itestablishes the order of execution for the evaluations and the enginecontrol functions and sends run responses to the engine controlfunctions and related DF modules that contain evaluations that arepermitted to run.

The DF modules and engine control (EC) function that receive runresponses from the dynamic scheduler module will now run/execute. Theevaluated data from the DF modules is used to determine whether or notthere is a fault present in the checked component/sub-system and also todecide whether or not DTC-data is to be created.

If an evaluation routine is interrupted due to changes in its physicalconditions (e.g. engine speed), or e.g. is finished for the rest of thedriving cycle, the related DF module takes this into account whencalculating the priority of that-evaluation routine.

When the dynamic scheduler module receives a response that an evaluationor engine control function has been stopped, the dynamic schedulermodule establishes the order of priority for the evaluations that areinhibited due to priority in addition to the evaluations that are stillrunning and, if permitted, sends run responses to the related DF modulesthat contain evaluations that are now no longer to be inhibited due topriority. This is repeated until the DSM module 90 sends a requestsignal to turn off all evaluations, i.e. to stop the diagnostic system.Requests to run from engine control functions which are not running arehandled in a similar manner.

This completes the overall normal operation for the diagnostic systemwhen no fault is present.

Overall Normal Operation When One or More Faults are Present in theDiagnostic System

The overall normal operation to inhibit affected evaluations and tostore the correct DTC (together with MIL illumination) in the diagnosticsystem 10 with one or several faults present is described in thefollowing:

If, during the overall operation described above for when no fault ispresent, an evaluation routine in a DF module detects a fault andgenerates evaluated data as “fault”, then the related DF module sendslatest evaluated data as “fault” to the dynamic scheduler module 30.

When the dynamic scheduler module receives a latest evaluated data as“fault”, it firstly inhibits the evaluations that are affected by thisfault and then establishes an order of priority between the remainingevaluations that are not affected by the fault, i.e. the evaluationsthat are inhibited due to priority a well as the evaluations that arerunning.

If another evaluation receives a latest evaluated data as “fault”, thedynamic scheduler module 30 inhibits the evaluations affected by thisother evaluation and so on for every-evaluation that reports a latestevaluated data as “fault”.

When a specific filtering of the evaluated data as “faults” iscompleted, the controlled data is set to “fault” in the related DFmodule for the remainder of the driving cycle. Immediately thecontrolled data is set to “fault”, the related DF module sends a requestto create DTC-data to the data collector module 40.

Upon the request to create DTC-data, the data collector module 40creates a DTC-block together with an extended FRZF and, when finished,sends a request to save this DTC-data (with the status “not validated”)to the DTC-data area module 50.

On the request to save the DTC-data, the DTC-data area module saves theDTC-block together with the extended FRZF and, when finished, sendsinformation to the validator module 60 that a not-validated DTC-blockhas been saved, and then sends the response that the DTC-block has beensaved to the data collector module 40.

When the validator module 60 receives the information concerning thesaved DTC-block from the DTC-data area module 50, it sets up a validatorchecklist that contains all the evaluations that are needed to, onrequest, respond that they have their controlled data as no-fault to thevalidator module before the validator module decides that the DTC-blockis valid.

The validator checklist is updated at the end of each driving cycle onrequest sent from the DSM module.

When the checklist is completed and the DTC-block is decided to bevalid, the validator module validates the not-validated DTC-block bysending a request to change the DTC-block status from not-validated tovalid to the DTC-data area module 50.

On request to change DTC-block status from not-validated to valid, sentfrom the validator module 60, the DTC-data area module 50 changes theDTC-block status from not-validated to valid and, when finished, sendsthe information that the DTC-block is valid to the related DF module.

When the DF module receives the information that a related DTC-block hasthe status “valid”, the DF module initiates and controls a DTC storeprocess and, when completed, sends a request to change the DTC-blockstatus from valid to stored to the DTC-data area module 50.

When the DTC-data area module receives the request to change DTC-blockstatus from valid to stored from the related DF module, the DTC-dataarea module changes the DTC-block status from valid to stored and thensends the information signal that the DTC-block has changed status tostored to the validator module 60.

When the validator module receives the information that a DTC-block haschanged status to stored, it erases the related checklist.

When the DF module receives the information that the related DTC-blockhas the status stored in the DTC-data area module, it will, inapplicable cases, send a request to the MIL handler module 70 toilluminate the MIL.

When the MIL handler module receives the request to illuminate the MILfrom the DF module, it illuminates the MIL.

The above-described creation, saving and status changing of DTC-datawill also be performed if another DF module sends another request tocreate DTC-data. However, handling of the current DTC-data is completedbefore handling of the next one, and so on for every DF module in thediagnostic system. In other words, once the DTC-data area module hasreceived an acknowledge signal from the validator module or, if thecurrent DTC-block status has changed to valid, an acknowledge signalfrom the current DF module, the DTC-data area module will handle any newrequest to save DTC-data.

If the DTC-data area module reports that a further new not-validatedDTC-block has been saved, the validator module 60 checks whether thecorresponding evaluation to this new DTC-block is to be found as anevaluation to be checked in the current checklist. If so, then thecurrent checklist and associated DTC-block are no longer the possibleroot cause to the fault and the validator module sends a request to thedata area module to erase the current DTC-block and then sets up anotherchecklist for the new DTC-block and so on until any DTC-block status ischanged to stored in the DTC-data area module 50.

If a DTC-block status has been changed to stored, the validator moduleerases the associated checklist.

This completes the overall normal operation to inhibit affectedevaluations and to store the correct DTC, together with MILillumination, in the diagnostic system 10 with one or severalfault-present.

The present invention is not restricted to the embodiments describedabove and shown in the drawings, but may be varied within the scope ofthe appended claims.

What is claimed is:
 1. A diagnostic system in an engine managementsystem for generating a diagnostic trouble code (DTC) to indicate theoperational status of a component or sub-system which is being evaluatedby said diagnostic system, said diagnostic system comprising: adiagnostic function module (DF module) for each DTC or a group ofrelated DTCs, said DF module including means (22) for executing anevaluation routine to evaluate the operational status of a component orsub-system to which the DTC of the specific DF module relates, and adynamic scheduler for determining which evaluation routine associatedwith said DF module may be allowed to execute at a particular time;wherein each said DF module comprises means for determining the prioritywith which the evaluation routine associated with that DF module shouldbe executed.
 2. The diagnostic system of claim 1, further comprising:means for producing a ranking value dependent on the operating status ofthe component or sub-system being evaluated, said ranking value beinggenerated each time an evaluation routine is performed; means forprocessing and storing statistical results of the ranking valuesobtained over a number of evaluation routines; means for evaluating saidstatistical results to produce evaluated data in the form of either anevaluated no-fault signal or an evaluated fault signal, and means fortransmitting said evaluated signals to said dynamic scheduler when achange in said signals occurs.
 3. The system as claimed in claim 1,wherein said dynamic scheduler (30) comprises means responsive to anevaluated fault signal to prevent other DF modules from performingevaluations if said other DF modules may be affected by said evaluatedfault signal.
 4. A diagnostic system in an engine management system forgenerating a diagnostic trouble code (DTC) to indicate the operationalstatus of a component or sub-system which is being evaluated by saiddiagnostic system, said diagnostic system comprising: a diagnosticfunction module (DF module) for each DTC or a group of related DTCS,said DF module including means for executing an evaluation routine toevaluate the operational status of a component or sub-system to whichthe DTC of the specific DF module relates, and a dynamic scheduler fordetermining which evaluation routine associated with said DF module maybe allowed to execute at a particular time; wherein each said DF modulecomprises means for determining the priority with which the evaluationroutine associated with that DF module should be executed; wherein saiddynamic scheduler comprises means, responsive to signals from enginecontrol functions and DF modules, for preventing other execution ofengine control functions or evaluations by DF modules if the otherengine control functions or the evaluations by DF modules interfere witha currently-performance control function or a currently performedevaluation by a DF module.
 5. A diagnostic system as claimed in claim 1,in an engine management system for generating a diagnostic trouble code(DTC) to indicate the operational status of a component or sub-systemwhich is being evaluated by said diagnostic system, said diagnosticsystem comprising: a diagnostic function module (DF module) for each DTCor a group of related DTCs, said DF module including means for executingan evaluation routine to evaluate the operational status of a componentor sub-system to which the DTC of the specific DF module relates, and adynamic scheduler for determining which evaluation routine associatedwith said DF module may be allowed to execute at a particular time;wherein each DF module comprises means for determining the priority withwhich the evaluation routine associated with that DF module should beexecuted; wherein said means for determining the priority with which theassociated evaluation routine should be executed comprises a calculationbased on when the evaluation routine associated with that DF module waslast executed.
 6. A diagnostic function (DF) module for executing anevaluation routine during a driving cycle to detect a fault in acomponent or sub-system in an engine management system and forgenerating a diagnostic trouble code (DTC) to indicate the operationalstatus of said component or sub-system, said DF module comprising: means(24) for determining the priority with which the evaluation routineassociated with the DF module should be executed.
 7. The DF module ofclaim 6, further comprising means for executing an evaluation routine toevaluate the operational status of said component or sub-system to whichthe DTC of the specific DF module relates, means for producing a rankingvalue dependent on the operating status of the component or sub-systembeing evaluated, said ranking value being generated each time anevaluation routine is performed; means for processing and storingstatistical results of the ranking values obtained over a number ofevaluation routines; means for evaluating said statistical results toproduce evaluated data in the form of either an evaluated no-faultsignal or an evaluated fault signal; means for receiving said evaluatedsignals from said means for evaluating said statistical results toproduce a controlled fault signal upon receipt of a predetermined numberof evaluated fault signals; means for deciding whether to store saidcontrolled fault signal in the form of DTC-data for the remainder of thedriving cycle; means for determining whether to erase any storedDTC-data, and means for deciding whether to illuminate or extinguish amalfunction indication lamp dependent on the stored DTC-data.
 8. Adiagnostic system in an engine management system for generating adiagnostic trouble code (DTC) to indicate the operational status of acomponent or sub-system which is being evaluated by said diagnosticsystem, said diagnostic system comprising: a diagnostic function module(DF module) for each DTC or a group of related DTCs, said DF moduleincluding means for executing an evaluation routine to evaluate theoperational status of a component or sub-system to which the DTC of thespecific DF module relates, and a dynamic scheduler for determiningwhich evaluation routing associated with said DF module may be allowedto execute at a particular time; wherein each DF module comprises meansfor determining the priority with which the evaluation routineassociated with that DF module should be executed; wherein said DFmodule further comprises means for comparing said evaluated data withpreviously generated data relating to evaluations of the component orsub-system to which the DTC of the specific DF module relates and, inthe event that an evaluated fault signal is generated, for comparingsaid signal with subsequently produced evaluated data to therebygenerate either a controlled fault signal or a controlled no-faultsignal.
 9. The system as claimed in claim 8, wherein said systemincludes a data collector module, and said DF module comprises means forsending a request to said data collector module to create DTC-data whena controlled fault signal is generated in said DF module.
 10. The systemas claimed in claim 9, wherein said data collector module comprisesmeans for creating said DTC-data, said DTC-data being in the form of aDTC-block containing the DTC and information pertaining to operatingconditions of the engine when said DTC was generated.
 11. The system asclaimed in claim 10, wherein said data collector module comprises meansfor transmitting said DTC-block to a validator module.
 12. The system asclaimed in claim 11, wherein said validator module comprises means fordetermining components or sub-systems on which the evaluated andsubsequently generated DTC-block depends, and means for obtaining datapertaining to the operational status of said components or sub-systemson which said controlled no-fault signal is dependent.
 13. The system asclaimed in claim 12, wherein said validator module comprises means forevaluating said data pertaining to the operational status of saidcomponents or sub-systems on which said controlled no-fault signal isdependent to thereby determine whether said DTC-block is valid.
 14. Thesystem as claimed in claim 13, wherein said validator module comprisesmeans for changing the DTC-block status to be valid in the event thatthe DTC-block is determined to be valid, and means for erasing theDTC-block in the event that the DTC-block is determined not to be valid.